001.Agentic RAG
传统的RAG
RAG: Retrieval-Augmented Generation 检索增强生成。RAG 通过结合 LLMS 的内在知识和外部数据库的非参数化数据，提高了模型在知识密集型任务中的准确性和可信度。
- 向量数据库：MIllvus,Chroma,PostgreSQL,Drant 等
- 数据的加载：html,markdown,pdf, excel,word 等
- 数据的切片（Chunk）：标题，段落，分隔符，语义等
- 嵌入（Embeddings） 模型：openai, bge-large 等
- 检索器：ANN（近似近邻检索），全文检索，过滤检索，混合检索，分组等
- Rerankers（重排序）：加权排序，RRFRanker 等
- Agent+RAG
- Graph +RAG
- 多源 RAG
- 评估 RAG：RAGAs（检索增强生成评估）框架
RAG 项目做到这几点
- 可以加载、解析文字和图片的 RAG；
- 拥有 NLTK 语义 Chunker 优化的 RAG；
- 可以分布式向量数据库的 RAG；
- 实现多路由、混合检索的 RAG；
- 多结果 ReRankers（重排模型）的 RAG；
- 和 Agent 整合的 RAG；
- 拥有 RAGAs（自我评估）的 RAG；
Agentic RAG
RAG + Agents= Agentic RAG。
Agentic RAG 描述了一种基于 Al Agents 的 RAG 实现。具体来说，它将 Al Agents 整合到 RAG 流程中，协调其组件并执行除简单信息检索和生成之外的其他操作，以克服传统 RAG 的局限性。
Agentic RAG 将 RAG 从一个“信息检索增强工具”彻底提升为一个“自主问题解决框架”。它为 RAG 注入了”灵魂”，使其能够处理动态、开放式、需要多步推理的复杂现实世界任务，这是之前所有阶段都无法企及的高度。
- 进化动机：为了解决最顶层的挑战——让系统能够像人类一样，自主地、有策略地去解决一个复杂问题。
- 核心理念：“不要给我固定的指令，告诉我你的目标，我自己来制定计划、选择工具、评估结果，甚至寻求同伴的帮助。”
- 关键技术与改进：这是 RAG 思想的一次范式转移，其核心是引入了 Al Agent。
- 从“数据流“到”推理环”：工作流程不再是线性的，而是一个由智能体主导的、循环往复的“思考-行动-观察〞循环。
- 自主工具使用（Autonomous Tool Use）：智能体在执行计划的每一步，都会自主判断并选择最合适的工具（搜索、计算、API 调用等）。
- 反思与自我评估：智能体会评估自己每一步的执行结果。它会主动调整计划，重新尝试，例如改写查询词、更换知识库等。
- 多智能体协作（Multi-Agent）：对于极其复杂的任务，系统可以创建一支“智能体团队”，每个智能体扮演不同角色（如研究员、分析师、批评家），它们分工协作，共同完成目标
传统 RAG vs Agentic RAG
提升数据质量优化
文本切割优化
- 问题：简单固定长度的分割会割裂语义（比如把一个句子从中间切断）。
- 优化：使用更高级的分割策略。
- 递归分割：先按段落/标题等大边界分割，再对过长部分进行二次分割。
- 语义分割：利用模型或算法识别语义连贯的单元。
元数据增强优化
- 问题：检索时只依赖纯文本内容，缺乏上下文。
- 优化：为每个文本块附加丰富的元数据，如：来源文件、章节标题、作者、创建日期、类型等。这些元数据可以用于混合检索或后处理过滤。
多模态数据优化
- 问题：PDF 或者扫描图中有图片，表格，和公式。如何实现 Any-To-Any。
- 优化：采用 OCR 模型解析多模态内容，并保留关键特征。并且采用多模态嵌入模型实现多模态向量化
Deepseek.OCR
Dots.OCR
Dolphin
GME-Qwen-VL 等等
提升索引优化
数据库索引优化
- 问题：近佐近邻搜索算法非常多，如何选择合适的算法和度量来加快搜索速度。
- 优化：选择 AUTOINDEX 来选择最合适的密集向量索引，同时给文字内容建立倒排索引提高速度。
- 使用 MaxScore 算法进行优化的 Document-at-a-Time （DAAT）查询处理。对于专业术语较多的情况下一定要选择 DAAT_MIAXSCORE
提升搜索质量优化
混合检索优化
- 问题：单纯基手语义的检索可能忽略关键词匹配的重要性。
- 优化：结合稀疏检索（如 BM 25）和稠密检索（嵌入模型）。BM 25 对精确关键词匹配更有效，两者结果融合可以取长补短。
- 重排：初步检索返回的 Top K 个结果中，可能混入一些相关性不高的文档。
- Rerank 模型：大模型
WeightedRanker
Qwen 3-ReRank 模型
检索结果评估优化
- 问题：检索返回的 Top K 个结果中，可能检索到的质量不佳或者最终大模型生产的答案出现幻觉。
- 优化：结合 RAGAS 框架，实现多种指标的评估
| 指标类别 | 指标名称 | 适用场景 | 评估重点 |
|---|---|---|---|
| RAG指标 | 上下文精度 | 检索精准度 | 检索结果中相关片段的比例 |
| RAG指标 | 上下文召回率 | 检索全面性 | 检索覆盖答案所需信息的比例 |
| RAG指标 | 上下文相关度 | 检索的相关性 | 检索结果和用户问题的相关性评估 |
| RAG指标 | 忠实度 | 生成内容质量 | 答案与检索内容的一致性 |
| RAG指标 | 回答相关性 | 生成内容质量 | 答案与问题的相关性 |
| 所有指标 | 答案准确性 | 生成答案的准确率 | 答案与给定问题的参考标准答案之间的一致性 |
提升回答质量和速度优化
上下文工程优化
- 问题：当上下文内容很长很多时，可能超出 LLM 的上下文窗口，或者关键信息被淹没。当用户的输入问题和历史聊天记录有关时需要有对应的解决方法
- 优化：对短期记忆和长期记忆进行管理，并且基于长期记忆进行语义混合检索。
上下文工程：LLM 失败的原因有以下两个：1、底层 LLM 能力不够；2、“正确”的上下文没有传递给 LLM。
上下文工程是以正确的格式提供正确的信息和工具，以便 LLM 能够完成任务。这是人工智能工程师的头号工作。
Tool 和 Agent
Tool（工具）
定义与功能
- 单一功能模块：Tool 是完成特定任务的独立工具，每个工具专注于一项具体操作（如搜索、计算、API 调用等）。
- 无决策能力：工具本身不决定何时被调用，仅在被触发时执行预设操作。
- 输入输出明确：每个工具需明确定义输入参数和输出格式，例如：
- 搜索工具：输入是查询字符串，输出是搜索结果。
- 计算工具：输入是数学表达式，输出是计算结果
通过这种分工，LangChain 实现了模块化与智能化的结合：Tool 提供基础能力，Agent 赋予系统自主决策的灵活性，两者协同完成从简单查询到复杂问题求解的多样化任务。
用户输入
↓
Agent（解析意图，生成计划）
↓
选择工具 -> 调用Tool1 -> 获取结果
↓
选择工具 -> 调用Tool2 -> 获取结果
↓
整合结果 -> 生成最终回答
MCP +Agent
MCP（Model Context Protocol，模型上下文协议），2024 年 11 月底，由Anthropic 推出的一种开放标准，旨在统一大型语言模型（LLM）与外部数据源和工具之间的通信协议。
Function Calling 是 AI 模型调用函数的机制，MCP 是一个标准协议，使 AI 模型与 API无缝交互，而 AI Agent 是一个自主运行的智能系统，利用 Function Calling 和 MCP 来分析和执行任务，实现特定目标。
MCP 与 Function Calling 的区别
| 类别 | MCP (Model Context Protocol) | Function Calling |
|---|---|---|
| 性质 | 协议 | 功能 |
| 范围 | 通用（多数据源、多功能） | 特定场景（单一数据源或功能） |
| 目标 | 统一接口，实现互操作 | 扩展模型能力 |
| 实现 | 基于标准协议 | 依赖于特定模型实现 |
| 开发复杂度 | 低：通过统一协议实现多源兼容 | 高：需要为每个任务单独开发函数 |
| 复用性 | 高：一次开发，可多场景使用 | 低：函数通常为特定任务设计 |
| 灵活性 | 高：支持动态适配和扩展 | 低：功能扩展需要额外开发 |
![[mcp通信.excalidraw]]
MCP 工作原理
MGP 协议采用了一种独特的架构设计，它将 LLM 与资源之间的通信划分为三个主要部分：客户端、服务嚣和资源
客户端负责发送请求给 MCP 服务器，服务器则将这些请求转发给相应的资源。这种分层的设计使得 MCP 协议能够更好地控制访问权限，确保只有经过授权的用户才能访问特定的资源。
以下是 MCP 的基本工作流程
- 初始化连接：客户端向服务器发送连接请求，建立通信通道。
- 发送请求：客户端根据需求构建请求消息，并发送给服务器。
- 处理请求：服务器接收到请求后，解析请求内容，执行相应的操作（如查询数据库、读取文件等）。
- 返回结果：服务嚣将处理结果封装成响应消息，发送回客户端。
- 断开连接：任务完成后，客户端可以主动关闭连接或等待服务嚣超时关闭。
MCP 通信机制
MCP 协议支持三种主要的通信机制：
- 基于标准输入输出的本地通信（stdio）；
- 基于 SSE （Server-Sent Events）的远程通信。是一种基于 HTTP 协议的单向通信协议，允许服务器以事件流的形式实时向客户端推送数据，而无需客户端明确请求。MCP 中的 SSE Transport 结合了 SSE 技术和HTTP POST
- Streamable：HTTP 是 MCP 协议推荐的下一代传输机制（3 月 26 日），基于标准 HTTP 协议实现动态流式升级的传输方式，它移除了专用 SSE 端点，所有消泉通过端点传输，服务器可根据需要将普通 HTTP 请求升级为 SSE 流，支持流式响应。
HTTP + SSE 的缺陷
远程 MCP 通过 HTTP •SSE的传输方式工作，存在以下问题，这也是它所被皆换的根本原因：
• 不支持恢复连接
如果客户端和服务器之间的 SSE 连接中断了，就无法“从端点继续”，只能重新开始新的连接，之前的上下文可能会丢失。
• 要求服务器保持高可用的长连接
服务器必须一直保持一个稳定、不中断的SSE 长连接，否则通信就中断。
• 服务器只能通过 SSE 发送消息
服务器无法在已有的请求之外，主动地发送消息给客户端，除了通过专门的/sse 通道。换句话说，它是“单向被动响应”，而不是“任意时机推送“”
FastMCP ：构建模型上下文协议（MCP）服务器的快速 Python 方案
Python 开发 MCP 服务：FastMCP
它提供了一种简单且高效的方法来构建 MCP 服务器，为开发者提供强大的工具和资源，从而帮助他们为 LLMs 提供上下文信息。
FastMCP 的主要特性：
- 快速：高层接口意味着更少的代码和更快的开发速度。
- 简单：构建 MCP 服务器时，所需的样板代码最少。
- Pythonic：符合 Python 开发者的直觉，使用起来更自然。
- 完整：致力于提供 MCP 规格的全面实现（当前某些高级功能仍在开发中）。。
- FastMCP 正在积极开发中，而 MCP 规格本身也在不断完善。